Date: Mon, 15 Feb 93 04:30:04 PST 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD. Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #41 

To: packet-radio 


Packet-Radio Digest Mon, 15 Feb 93 Volume 93 : Issue 41 


Today's Topics: 
MOCOM 70 modification experience (2 msgs) 
msg traffic for kd7hp@mso plus a question 
Newsreader for NOS NNTP server? 
Packet-Radio Digest V93 
Packet Modem Prices and Speeds? (2 msgs) 
Palmtops and packet? 
Posting to NOS NNTP (2 msgs) 
Welcome to rec.radio.info! 
Yaesu FT-990 & PK232MBX Users? 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 14 Feb 93 23:39:29 CST 

From: tulane!agwbbs!Angelo_Glorioso_Iii@ames.arpa 
Subject: MOCOM 70 modification experience 

To: packet-radio@ucsd.edu 


Hi Dave, 
We have several of them in use here in New Orleans and thourgh out the 
Gulf coast.. We are using 446.100 thought.. This is about as low as they 


can go.. 


73, Angelo 


-- Via DLG Pro v0.995 


Internet: angelo_glorioso_III@agwbbs.new-orleans.LA.US 
Usenet: rex!agwbbs!angelo_glorioso_III 
Packet:N5UXT @ N5UXT.d#NOLA.LA.USA.NA 
Tcp/ip:N5UXT.AMPT.ORG [44.108.2.13] 


Date: 14 Feb 93 23:35:56 CST 

From: tulane!agwbbs!Angelo_Glorioso_Iii@ames.arpa 
Subject: MOCOM 70 modification experience 

To: packet-radio@ucsd.edu 


Hi Bob, 
We have several of the Mocom 70 UHF radios running at 9600 Bps here in the 


Gulf coast area.. They work good. If you leave me your address, I will be 
glad to mail you a copy of the mod.. 


73,Angelo 
-- Via DLG Pro v0.995 


Internet: angelo_glorioso_III@agwbbs.new-orleans.LA.US 
Usenet: rex!agwbbs!angelo_glorioso_III 
Packet:N5UXT @ N5UXT.#NOLA.LA.USA.NA 
Tcp/ip:N5UXT.AMPT.ORG [44.108.2.13] 


Date: Mon, 15 Feb 1993 06:20:34 GMT 

From: usc!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu! 
usenet.coe.montana.edu!selway.umt.edu! petey@network.UCSD.EDU 
Subject: msg traffic for kd7hp@mso plus a question 

To: packet-radio@ucsd.edu 


Hello all. I am a tech. (n7xla) in Missoula mt. I have not 
gotten on Missoula Packet yet. Is there a packet gateway to the Internet? 


This way I can send E-mail to my friend, kd7hp who has a packet BBs in 
Missoula. I have heard of a gate in Penn. however being that I just got 
on I saw no FAQ post. If there is no formal gate, would someone 

handle my msg traffic? Please e-mail me @petey@selway.umt.edu 


thanks 


Date: Sat, 13 Feb 1993 17:31:30 GMT 

From: sdd.hp.com!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1! 
ritchie.uwaterloo.ca! owpurbo@network.UCSD.EDU 

Subject: Newsreader for NOS NNTP server? 

To: packet-radio@ucsd.edu 


I have been using fsuu12r4.zip as newsreader 
for my NOS NNTP server for quite awhile. 

It works fine for reading the news (in fact, 
it is quite similar to Rn in UNIX). 


Unfortunately, to follow-up, reply and post an article 
it doesn't modify the /spool/news/history + 

some other incompatibilities in the directories. 

Well, actually it works - but I have to manually 

edit the /spool/news/history by hand :-( 


Would appreciate any info on a decent newsreader 
fully compatible with NOS NNTP server 
(hopefully with source code :-) ..... 


Thank you. 


73 Onno YC1DAV/VE3 -sk- 
ycidav@ve3.ycidav.ampr.org [44.135.84.22] 


Date: 15 Feb 93 03:10:39 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Packet-Radio Digest V93 
To: packet-radio@ucsd.edu 


Reply to: RE>Packet-Radio Digest V93 #39 
Having seen the blurb about NosIntro and NosView I thought I would add my two 
penn'orth. 


Some while ago I arranged with Ian to distribute NosView over the Internet (as 
he does not have accesss) and it was made available on ucsd.edu and on tomcat. 
As far as I'm aware it is still there on those machines. However I have not 
received an update for some time and it is likely that a more recent version 
exists. Having just received a leaflet advertising NosIntro (first I've heard 
of it) I have replied ordering a copy and also reminding Ian to send me NosView 
for uploading onto the Internet. 


If a new copy arrives I will upload it and post details here. 


Nigel Watkinson 


ax25: GONGL@GB7NWP.##16.GBR.EU 
internet: nigel@sna.co.umist.ac.uk 
fax +44-61-200-3324 

cix: nigelw 


Date: Sun, 14 Feb 1993 14:06:45 GMT 

From: usc!wupost!emory !wa4mei! ke4zv! gary@network.UCSD.EDU 
Subject: Packet Modem Prices and Speeds? 

To: packet-radio@ucsd.edu 


In article <1993Feb13.225757.18658@fcom.cc.utah.edu> val@fcom.cc.utah.edu (Val 
Kartchner) writes: 

>I'm just starting to study for my license. (The local club just started a 
>class.) I was wondering about the price of packet modems and which speeds 

>I should look into getting? 

> 

>As an example of the type of reply that I'm looking for, here's an example 
>for (telephone) modems: 


Almost all modems will automatically connect at the highest common speed. 
300 and 1200 bps modems are effectively obsolete. 2400 bps is the lowest 
speed that you should even consider getting, but many BBS's still have 
only this speed. 9600 bps (v.32) is common for new purchases, but for 

a little bit ($50-$100) more, you can have 14400 bps (v.32bis). The 
28800 bps (nicknames v.fast/v.last) is comming out "real soon now", but 
since many computers can't keep up, it may be better to stay with v.32bis. 


VV VV VV VV 


Packet doesn't work this way, at least not completely. There's no call 

setup negotiation in the packet world. Packet can be sent two different 
ways, Virtual Circuit and Datagram. It's theoretically possible to negotiate 
a VC connection speed, but with multi-connects or datagrams the modem has 

to be able to decode every packet it hears. That makes negotiated speeds 

a problem. Normally different speeds are used on different frequencies 

and operators set them manually to match the other stations on the channel. 


The two basic speeds are 300 and 1200 baud, both based on the half duplex 
Bell 202 standard tones. 300 baud is used on HF and 1200 is used on VHF 
due to regulatory issues and practical multipath issues at HF. Kantronics 
introduced their 2400 baud modulation scheme some time ago and other 
manufacturers have followed it so that all 2400 baud modems will talk 

to each other. Some TNCs have dual modems and will respond to either 

Bell 202 1200 baud or to 2400 baud Kantronics format packets. Origination 
speeds have to be selected manually. 


Above 2400 we have the KING inspired 9600 baud modem. The most common 
implementation is the one by G3RUH. Again there are TNCs that can support 
this modem as a secondary modem and select downwards to Bell 202, but they 
aren't common. Also, at this speed most voice grade radios need modifications 
to work properly. 


As we go to the higher speeds, we must discard the voice grade radio 
approach. At 19.2 kilobaud, most users are directly FSKing special 
purpose radios such as the Kantronics D4, though some are using the 
Kantronics 19.2 kb modem which includes a scrambler to prevent bit 
bias. When you go to the GRAPES 56 kilobaud modem, the modem xbecomes* 
the radio. This unit uses a modulation scheme called MSK for Minimum 
Shift Keying. It includes a scrambler and a tracking data detector 
that will handle off frequency and drifting signals at UHF. That's as 
fast as available equipment supports today. 


There are faster systems in use experimentally. The GRAPES modem 

can be speed doubled to 112 kb, and there are experimental 100 kb to 
1 megabaud microwave radios in operation on the West Coast. Finally, 
a few hams have experimented with ethernet over microwave at 10 GHz. 
This gives a potential data rate of 10 megabits per second. 


>As a packet protocol, EC (error correction) is inherent in the protocol, 
>correct? Would a TNC with builtin DC (data compression) (effectively) be 
>ruled out because of the FCC restriction on "clear text" transmission? Or, 
>would it be ruled out because of the need of the remote modem to maintain 
>an updated compression table which isn't feasible? 


The packet protocol in use at the link level, AX25V2, does not support 
error correction. It does support error detection. When used in VC mode, 
it operates as an ARQ protocol with the receiving station sending ACKS or 
acknowledgement packets for correctly received frames. The transmitting 
station will resend any packets for which it doesn't receive an ACK within 
a specified timeout interval. In essence this is similar to the venerable 
XMODEM protocol used for file transfer by landline systems. When used in 
datagram mode, AX25V2 does not do ACKs and so is not an ARQ protocol. 
That function moves to a higher level in the protocol stack, such as 

the TCP level of the TCP/IP protocol suite that is often used by amateurs 
on top of the AX25V2 link layer. 


New schemes, called Pactor and Clover are in use at HF that do include 
elements of FEC, Forward Error Correction, allowing the receiving station 
to reconstruct damaged frames. At VHF and UHF the channel error rate is 
usually low enough not to warrant the overhead of FEC schemes. Either the 
frame gets through undamaged, or it's so totally clobbered by a collision 
that FEC doesn't help. 


Data compression, either on the fly or compressed file transmission, 

is perfectly legal on the amateur bands xif*x the compression is meant 

to facilitate communications and is not intended to obscure meaning. 
This is not considered encryption under the rules, IE it is still "plain 
text" assuming you have the proper decompression software. Encryption is 
generally illegal except for certain telecommand functions. Any published 
scheme that can be reproduced by any other similarly equipped amateur is 
perfectly acceptable. Even systems that are not in wide public use are 
acceptable if station records are kept of the compression algorithm to 
allow the FCC to decompress any transmissions they may have intercepted. 
Systems that require confidential private keys are *not* acceptable. 


I haven't heard of anyone using on the fly compression, and don't know 
of any commercial implementations for TNCs, but compressed binary file 
transmissions using schemes like PKzip are routine. I think I've heard 
of some forwarding BBS systems using message compression, but I don't 
know if it's done on the fly or in advance of transmission. 


I hope this summary is useful. 


Gary 

Gary Coffman KE4ZV | You make it, | gatech!wa4mei! ke4zv! gary 
Destructive Testing Systems | we break it. | uunet!rsiatl! ke4zv! gary 
534 Shannon Way | Guaranteed! | emory!kd4nc!ke4zv! gary 
Lawrenceville, GA 30244 | 


Date: 15 Feb 1993 03:18:23 -0500 

From: usc!hela.iti.org!cs.widener.edu!widener! nobody@network.UCSD.EDU 
Subject: Packet Modem Prices and Speeds? 

To: packet-radio@ucsd.edu 


In article <1993Feb13.225757.18658@fcom.cc.utah.edu> val@fcom.cc.utah.edu (Val 
Kartchner) writes: 

> 

>As an example of the type of reply that I'm looking for, here's an example 
>for (telephone) modems: 


Another feature that you should look for is built-in error correction 
and data compression. v.42bis compression can get (theoretically) up 
to a 4:1 compression ratio making a 14400 bps modem effectively a 

57600 bps modem. However, the peak expected compression is about 2:1. 


VV VV VV 


>As a packet protocol, EC (error correction) is inherent in the protocol, 
>correct? Would a TNC with builtin DC (data compression) (effectively) be 
>ruled out because of the FCC restriction on "clear text" transmission? Or, 


>would it be ruled out because of the need of the remote modem to maintain 
>an updated compression table which isn't feasible? 


I am going to purchase a Packet Data Engine this Dayton. If anyone is 
interested, I would like to develop some new software for it. 
Preferrably something to do data compression at high speed. Any takers? 


73, 

stuart b. tener, n3gwg 
tener@cs.widener.edu 
(215) -338-6005 


Date: Mon, 15 Feb 93 03:49:21 GMT 

From: mnemosyne.cs.du.edu!nyx! jmaynard@uunet.uu.net 
Subject: Palmtops and packet? 

To: packet-radio@ucsd.edu 


In article <1993Feb13.205732.16290@magnus.acs.ohio-state.edu> 
jmilhoan@magnus.acs.ohio-state.edu (JT) writes: 

>I think an hp95-1x or some other palmtop which is more like a true-PC 
>would be much nicer than a Wizard because of all the ham software 
>available for the DOS platform. The hp95-1x has a serial port, but I 
>don't think it has a slot... at least not the "type 2" slots which the 
>modems are being made for. Type 1 is just for memory cards (I think! 
>I'm not positive on the slot-thang). 


The HP95LX runs a slightly modified version of KA9Q very nicely, thank 
you. One caution, though: the serial transmitter eats batteries. 


I don't think a PCMCIA TNC would sell well; there aren't any palmtops I'm 
aware of yet that have Type II slots, and while there are Type I modems, 
there's quite a bit more market for those, and they're very machine 
specific (because they have to run special software to talk to the modem 
aS a memory-mapped device, since all Type I supports is memory). 


(BTW, does anyone know if the mods I made for the 95's serial port got 
folded into the stock KA9Q [or variant thereof] software? They should work 
OK on normal machines... If not, I'll pick up a current copy of one of the 
packages' source code, or get with any or all authors and describe the 
necessary mods.) 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can 
jmaynard@oac.hsc.uth.tmc.edu | adequately be explained by stupidity. 
"Support your local medical examiner - die strangely." -- Blake Bowers 


Date: Sat, 13 Feb 1993 17:24:51 GMT 

From: sdd.hp.com!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watserv1! 
ritchie.uwaterloo.ca! owpurbo@network.UCSD.EDU 

Subject: Posting to NOS NNTP 

To: packet-radio@ucsd.edu 


In article <1993Feb11.180355.16233@csusac.csus.edu> chuckb@babbage.csus.edu (Chuck 
Bland) writes: 

>OK, so I can GET news from an nntp news server with NOS. How to I 

>POST news from one nos node to my nntp server, rf or otherwise ? 

> 

>Chuck Bland 

>chuckb@babbage.ecs.csus.edu 

>nédbt 


Chuck: 
If your NOS is compiled with NNTP server built-in 
you should be able to do it easily by turn on 
the: 

nntp ihave 1 


In fact a couple of us have been doing NNTP forwarding 
between NOS NNTP servers in AMPRNet for a couple of months now. 


Unfortunately, the off-the-shelf NOS.EXE (from ucsd.edu) 
doesn't come with NNTP server built-in - 

Some have NNTP client built-in but not NNTP server 

so you have to compile it yourself. 


73 Onno YC1DAV/VE3 -sk- 
ycidav@ve3.ycidav.ampr.org [44.135.84.22] 


Date: 14 Feb 93 12:59:06 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Posting to NOS NNTP 

To: packet-radio@ucsd.edu 


I have written a utility valled PNEWS which does exactly this: Post 
articles to specified NNTP groups. It is based partially on code 
developed by EI9GL (Paul Healy) for BMHO2 and by Bdale Garbee for 
BM.EXE. You should be able to find it on UCSD.EDU. 

There is also a new release with some bug fixes, but I cannot ftp 
to ucsd.edu anymore. If someone would like to upload it there, 


I can send him a floppy disk by mail. 


73 Costas SV1XV (ex G7AHN) 


| Dr. K. Krallis SV1XV x Epsilon Software S.A. 


Internet: kkrallis@leon.nrcps.ariadne-t.gr 

Packet radio: SV1XV @ SV1IW.ATH.GRC.EU 

AMPRnet: svixv@svixv.ampr.org [44.154.1.11] 
Snail Mail: P.0.BOX 3066, GR-10210 Athens, GREECE 


Date: Mon, 15 Feb 93 02:04:42 MST 

From: cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!ersys! ve6mgs!rec-radio- 
info@beaver.cs.washington.edu 

Subject: Welcome to rec.radio.info! 

To: packet-radio@ucsd.edu 


Archive-name: radio/rec-radio-info/welcome 
Last-modified: $Date: 1993/02/14 09:17 $ 
Version: $Revision: 1.02 $ 


xxk Welcome to rec.radio.info! «xx 


Welcome to rec.radio.info, a group that aims to provide a noise-free source 
of information and news for the entire rec.radio hierarchy. 


Two introductory articles about rec.radio.info are posted to the group and 

to news.answers every two weeks. You are now reading the first article, which 
explains what rec.radio.info is, and answers some Frequently Asked Questions. 
The second article is titled "Submission Guidelines", and you only need to 
read it if you want to submit an article to rec.radio.info. 


-- What is the purpose of rec.radio.info? 


The purpose or charter of rec.radio.info is to provide the Usenet community with 
a resource for information, news, and facts about any and all things radio. 


All the other rec.radio groups are intended for discussions and general chit 
chat about radio. Rec.radio.info will contain informational, factual articles 
only. Follow-ups are redirected to an appropriate other group, and further 
discussion (if any) will not take place in rec.radio.info. 


In order to ensure that rec.radio.info contains only appropriate articles, it 


was decided to create the group as a moderated newsgroup. 
-- Why are messages almost always cross posted to rec.radio.info? 


It provides a "tag" for each article to be assembled into a filtered 
presentation in rec.radio.info (even with cross-posting, only one message, with 
a unique Message-ID, is propogated across the net). This tag also facilitates 
a pre-existing method of dropping or cancelling the articles locally within the 
discussion groups if you don't want to see them. This accommodates individuals 
who want to separate the bulletins from the discussions, discussions from the 
bulletins, as well as those who are adamant about not reading another 

newsgroup and wanted to see everything all in one basket. 


With the total size of Usenet (in number of newsgroups and total traffic) 
doubling every year or so, this is no insignificant contribution to reducing 
information noise and chaos. Making the discussion groups a catch-all, and 
making extra newsgroups filters on that catch-all, is also the most realistic 
way to implement such a scheme (It's not intuitively obvious what the charter, 
contents, and general appropriate topics for each and every newsgroup are. 
Seeing FAQ's and charter/intro postings in the home newsgroup is beneficial 
for new readers). 


By cross-posting one only is adding a few tens of bytes to each bulletin (to 
specify the extra group on the Newsgroups line), but are adding the capability 
for very powerful filtering features available on most news servers and 
readers. Your local news guru could probably explain these features in more 
detail. 


-- What is a 'follow-up', and what does 'moderated' mean? 
If you are new to Usenet and are not familiar with the terminology, you might 
want to read the general introductory articles found in the newsgroup 
news.announce.newusers. Doing so will make your life on the net much easier, 
and will probably save you from making silly beginner's mistakes. 
If you think that at this moment you are reading an echo, a conference, or 
a bulletin board, I'd also strongly suggest a trip over to 


news.announce.newusers. 


For the rest of this article, I will assume you have a basic knowledge of 
Usenet terminology and mechanics. 


-- OK, so now I know what 'moderated' means. Tell me more. 


Rec.radio.info is a moderated newsgroup, which means that all articles 
submitted to the group will have to be approved by the moderator first. 


The current moderator of the group is Mark Salyzyn. Submissions to 


rec.radio.info can be posted, or e-mailed to: 
rec-radio-info@ve6mgs.ampr.ab.ca 


Comments, criticisms, suggestions or questions about the group can be e-mailed 
to: 
rec-radio-request@ve6mgs.ampr.ab.ca 


But before you do so, please be sure to check out the "Submission Guidelines" 
article. 


The influence of the moderator should be minimal and of an administrative 
nature, consisting chiefly of weeding out obviously inappropriate articles, 
while making sure correct headers etc. are used for the appropriate ones. 


-- What type of material is considered inappropriate? 


There are three broad categories of articles which will be rejected by the 
moderator: 


1) Requests for information: rec.radio.info is strictly a one-way street. I 
receive information in my mailbox; I then post it to rec.radio.info. 
Requests for specific information belong in the normal discussion newsgroups. 
If your request gets answered, you might consider passing the answer on to 
rec.radio.info, though. Especially if you can edit it into a informational, 
rather than a discussion, format. 


2) Obvious discussion articles, or articles that appear unsubstantiated. 


3) Commercial stuff: a relatively unbiased test of a radio product would be 
accepted, but any hint of for-profit might be reason for rejection. For three 
reasons: This is not the purpose of the list, for-profit is a controversial 
topic, and this list may be passed onto Amateur Packet Radio (where 
for-profit is prohibited except under certain provisos). 


rec.radio.swap may be more deserving of the posting in any matter. 


Similarly, copyrighted material generally cannot be used. If it's TRULY 
worthwhile to the net, I would recommend obtaining permission from the 
copyright holder. Please note the source, and if permission was given. I 
reserve the right to make the final decision concerning appropriateness in 
all situations. In most cases, a brief summary of, or pointer to, the 
copyrighted information may be all I can allow. 


-- I do not have access to news, how can I get the information posted to 
rec.radio. info? 


brian@UCSD.EDU (Brian Kantor) has kindly supplied a mail list server for 


rec.radio.info. Non of the articles will be digested, due to their size, so 
you will receive individual mailings for every article posted to the group. 


Mail sent to radio-info@ucsd.edu will be forwarded to the moderator and 
thus is an alias to rec-radio-info@ve6émgs.ampr.ab.ca 


To subscribe and unsubscribe via the listserver; the format for that is 


sub address radio-info 
unsub address radio-info 


where ‘address’ is your full mailing address. Send this request to 
listserv@ucsd.edu 


Note that the server will automatically delete any address that bounces mail. 
If you leave the address portion blank, it will try to deduce your address 
from the mail headers. This may not work if you are on bitnet, milnet or 
some other non-Unix host, so it is recommended to put your return address 

in any case. For example: 


sub mymailbox@myhost.mydomain.mil radio-info 
or 
sub MEMEMEOQ1@DMBHST.bitnet radio-info 


or something like that. 
-- Will the material appearing in rec.radio.info be archived somewhere? 


Yes. Still firming up details at the moment but here is a preliminary list: 
- unbc.edu as maintained by Lyndon Nerenberg <lyndon@unbc.edu> 
- nic.funet.fi maintained by Risto Kotalampi <rko@cs.tut.£1i> 
saved to /pub/dx/text/rec.radio.info currently stored as 
numbered files. 


Effectively this means that anything you post to rec.radio.info will be 
permanently stored, so your work will not be lost. 


-- I have a regular posting with timely information, is there a way to 
speed up it's delivery, or automate for more convenience? 


Yes, there is! It may take a bit of chatter with the moderator, but we are 
willing to take responsible people and provide them the means of posting the 
articles directly from their site. We will try everything we can as we fully 
realize that DX (distant signal) and astronomical data can be somewhat 
transitory. We are also willing to allow regular posters of information the 
same courtesy, even if the information is not as timely. 


We refer to this as self-moderation, which is partly based on the model for 
news.answer. This requires co-operation and good will to be beneficial to 
the community in the rec.radio hierarchy. 


I suggest reading the posting guidelines for more information. I am open to 
suggestions. 


I thank the following individuals for their input into this article: 
The rec.music.info moderator ... 
The rec.radio.broadcasting moderator Bill Pfeiffer wdp@gagme.chi.il.us 
Paul W. Schleck, KD3FU pschleck@unomaha.edu 
Ian Kluft, KD6EUI ikluft@uts.amdahl.com 


Mark Salyzyn -- Moderator rec.radio.info 

Submissions to: rec-radio-info@veémgs.ampr.ab.ca 

Administrivia to: rec-radio-request@ve6mgs.ampr.ab.ca 

* Requests for information do xnotx belong in rec.radio.info x 


Date: Fri, 12 Feb 1993 15:50:56 GMT 

From: mvb.saic.com!unogate!news.service.uci.edu!usc!zaphod.mps.ohio-state.edu! 
pacific.mps.ohio-state.edu!cis.ohio-state.edu!udecc.engr.udayton.edu!udcps3! 
dmapub! apontej@network.UCSD.EDU 

Subject: Yaesu FT-990 & PK232MBX Users? 

To: packet-radio@ucsd.edu 


I am interested in talking to users of the above equipment that use it on the 
20m band. Also anyone else who has used it for or on remote control operator 
which as I understand the FCC rules is legit, since only a few have the FCC STA 
for automatic operation. My desire is to interface the PC to change frequencies 
and change other parameters to stay locked in to or connected to others in the 
main 20 m frequencies. At present I am reading the documenation manuals for the 
TNC and the Transceiver and experimenting manually, I believe the TNC has a 
technical manual which I should get..Does anyone know if AEA is on packet or 
what would someone packet address will be at AEA? Maybe the internet or packet 
address of the author of the software which come with the PK232MBX (Ed L...) do 
no remember his name. If anyone has done this allready on HF please contact me/ 


I plan to use some of the PK monitor command to determine if I am on frequency 

and change it accordingly, along with other tranceiver or TNC coomads. Like I said 
I am still experimenting manually with limited sucess maybe due to unfamiliarity 
with the software package or equipment. 


The call sign being used is the club station W8BI. 


I acan be reached via internet email or packet at either 


N8WPB@W8BI .4#tday.oh.usa.na or n8wpb@n8acv.#day.oh.usa.na 


End of Packet-Radio Digest V93 #41 
KKKKKKKKKKKKKKKKKKKKKEKKEKRKR RK KK 


